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(54) A method and apparatus for dynamically creating message mailboxes 



(57) A system that dynamically creates a mailbox if 
the mailbox does not exist for a message at the time that 
the message is to be stared when dynamic mailbox cre- 
ation is enabled. A system level process indicates that 
the mailbox exists and provides default subscriber infor- 
mation to a voice messaging application during the re- 
ceipt of a message when a mailbox does not exist on 
the system for the recipient of the message and dynamic 
mailbox creation is enabled. At the time the message is 
to be stored the mailbox is created with the default sub- 



scriber information. The system checks for erroneous 
mailbcxes by requesting confirmation of the recipient 
telephone number from the telephone system using a 
message waiting indication packet. This check can be 
performed befcre the mailbox is created when the mail- 
box address is available, while the message is being 
held before being stored, or it can be used to delete the 
mailbox after it is created. When the message is re- 
trieved, the mailbox is initialized. Mailboxes that are not 
initialized and that are dynamically created are deleted 
after a mailbox expiration time period has elapsed. 
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BACKGROUND OF THE INVENTION 

Field of the Invention s 

The present invention is directed to dynamically 
creating a message mailbox, such as a voice mailbox, 
as the mailbox is needed and, more particularly, to a sys- 
tem for creating a system-wide mailbox at the system 10 
or platform level and at the time the mailbox is actually 
needed. 

Description of the Related Art 

75 

Conventional systems require that a message mail- 
box, such as a voice mailbox, a facsimile mailbox, a vid- 
eo mailbox, an e-mail mailbox, etc., be created and ac- 
tivated prior to the mailbox being used by a subscriber 
or callers of the subscriber That is, conventional sys- 20 
terns require that a service provider "provision" mailbox- 
es on a system before the system allows the mailbox to 
receive messages. The provisioning of mailboxes can 
be accomplished in two general ways: 1 . create all the 
mailboxes that will be needed ahead of time, that is, as- 25 
sumethat every telephony customer has a mailbox (uni- 
versal provisioning); or 2. require that a subscriber con- 
tact a customer service representative to subscribe to 
the service, with the customer sen/ice representative 
creating and activating the mailbox. The first method 30 
wastes resources because typically much less that 50% 
of a customer base subscribes to a voice mail service. 
The first method also slows performance because a 
very large set of subscriber records must be searched 
each time a mail box is accessed. The second method 35 
involves a customer service agent, which is costly and 
time consuming. 

Systems have been produced in which a voice mail 
application program creates a mailbox upon call arrival 
at the voice mail system if the mailbox does not exist, in 40 
such systems where mailboxes are created without ex- 
ception, the voice mail system must be assured that the 
system receives only calls that are destined to subscrib- 
ers of the voice mail system, i.e. the system does not 
receive calls that are destined to non-subscribers. The 45 
problem in such systems is that ail call arrivals create a 
mailbox, even when a called number is not that of a sub- 
scriber, (eg. a wrong number was dialed or the call is to 
a pay telephone) or the calling party is not a subscriber 
(eg. a pay telephone is the source of the call). Because $0 
the mailbox is created upon arrival, these systems also 
create a mailbox even when the calling party decides 
not to leave a message or hangs up after a few seconds 
of silence. This created mailbox is permanent and re- 
mains on the system even if a message is not stored in 55 
the mailbox. These systems, like the universal provi- 
sioning systems, create mailboxes that are not needed, 
which wastes system resources. 
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It is also often the ca^lfe a subscriber to a voice 
mail service will want to and some service providers 
would prefer to allow subscribers to send or leave mes- 
sages for non-subscribers or for subscribers of other 
voice mail systems ( a non-local subscribers") for an extra 
fee. In such situations it is not practical to provision for 
all possible message recipients as discussed above. 

Problematically, automatically created mailboxes is 
that the process can be subject to "hackers". A hacker 
could set up a mailbox for a pay telephone and thereaf- 
ter send and receive messages without being billed. 

Another problem associated with automatically 
treated mailboxes is that the number of recipients may 
be incorrect. 

Many telephony sen/ice providers are considering 
the deployment of universal messaging systems that 
provide voice mail messaging service as part of the tel- 
ephone subscribers' basic service. In such systems, if 
the mailboxes are created by service agents, a system 
the administrative burden of creating a mailbox for each 
subscriber using service agents is also great. 

What is needed is a system that automacically and 
dynamically creates a mailbox as the mailbox is actually 
needed for valid telephone numbers without the previ- 
ously required administrative burden. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a 
mailbox creation system that creates a mailbox when it 
is actually needed, that is, when a message exists to be 
stored for a valid, called number that does not already 
have a mailbox. 

It is another object of the present invention to allow 
customers to use a messaging system in a natural way 
(eg. inputting the mailbox numbers of people to whom 
they want to send messages), and to have the messag- 
ing system automatically create mailboxes for valid 
numbers that were input and that do not already have 
mailboxes. 

It is an additional object of the present invention to 
dynamically create a mailbox when one has not existed 
before so that a message can always be left. 

It is a further object of the present invention to verify 
that a mailbox being created is valid. 

It is also an object of the present invention to create 
mailboxes only for tekephone numbers that are to be 
provided with messaging service. 

It is an object of the present invention to remove 
dynamically created mailboxes that do not have their 
messages retrieved within a predetermined time period. 

The above objects can be attained by a system that 
provides default subscriber information to a voice mes- 
saging application during the receipt of a message 
whenever a mailbox does not exist on the system for the 
recipient. The message for the mailbox is temporarily 
held until the message must be stored in a mailbox. 
Then, if necessary, the mailbox is created and the mes- 
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sage is stored therein. The sys^^^ecks for erroneous 
mailboxes by requesting confirmation of the recipient 
telephone number from the telephone system. This 
check can be performed before the mailbox is created, 
while the message is being held, or it can be used to s 
delete the mailbox after it is created. 

These together with other objects and advantages 
which will be subsequently apparent, reside in the de- 
tails of construction and operation as more fully herein- 
after described and claimed, reference being had to the 10 
accompanying drawings forming a part hereof, wherein 
like numerals refer to like parts throughout. 



BRIEF DESCRIPTION OF THE DRAWINGS 



DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 
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Figure 1 depicts a typical voice mail system to which 
the present invention can be applied; 
Figure 2 illustrates the process performed in ac- 
cordance with the present invention; 
Figure 3 depicts mailbox creation upon a login at- 20 
tempt; and 

Figure 4 depicts a mailbox validation process. 
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A message storage and retrieval "platform" or sys- 
tem 10, such as illustrated in figure 1, can have many 
sources of messages. The typical message is produced 
by a user, a "calling party", using a telephone 12 to tel- 30 
ephone another person, a "called party", over a public 
switched telephone network (PSTN) 14. In the typical 
call flow the call is handled by a central office (CO) 
switch 1 6 until the called party does not answer or a busy 
is detected by the CO switch 1 6. At that time the call is 35 
transferred to the messaging system 10, where the call 
is routed to one of several application processing units 
(APU) 20 by a routing device such as a digital switch 
(SW) 22. The APU 20 performing a messaging function 
or process (such as voice mail, facsimile mail, call an- 40 
swering, etc.) typically checks with and obtains a mail- 
box address for a message to be recorded from a control 
unit (CU) 24 or some platform-level process. The APU 
20 stores the message and informs the CU 24 where 
the message is stored. In this transaction the telephone 45 
number of the called party can be provided via a sign- 
aling path (using a well-known communication protocol, 
such as SMDI, SS7, ISDN, DID or ANI) between the CC 
16 and the CU 10 (and the CU 24 provides the number 
to the APU 20) or the number can be provided directly so 
to the APU 20 by the calling party entering the called 
telephone number again during call answering and mes- 
saging operations performed by the APU 20. The enter- 
ing of the telephone number by the calling party can also 
occur when a subscriber listening to stored messages ss 
decides to send or forward a message to another sub- 
scriber. 

A message can also be received as a "transferred 
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message" (using a well kj^^protocol, such as AMID- 
Analog or AMIS-Digital) that was originally recorded by 
another message recording system 30. Such trans- 
ferred messages typically arrive via a network process- 
ing unit or network interface unit 32 and are typically 
processed in much the same manner as messages re- 
ceived through the APU 20. 

Messages can also be recorded through or trans- 
ferred over other types of networks such as the Internet 
34. These messages can be from a telephone or from 
a computer. (See US patents 5,029,199; 5,193,110; 5, 
260,990; 5,263,080; 5,402,472; 5,475,748; 5,493,607; 
5,519,766 and 5,008,926, and US application entitled A 
System For Accessing Multimedia Mailboxes And Mes- 
sages Over The Internet And Via Telephone, assigned 
to Boston Technology Inc. and having docket number 
782.1033, all incorporated by reference herein). 

As illustrated in figure 2, typical messaging sys- 
tems, such as the preferred CO ACCESS® system and/ 
or the Access NP™ system available from Boston Tech- 
nology, Inc. of Wakefield, Massachusetts, have a sys- 
tem-level process 40 that interacts with an application- 
level process 42 to perform the messaging operation. In 
distributed systems, such as shown in figure 1 , the sys- 
tem level process 40 typically runs on the CU 24 or on 
a database processing unit (not shown) or possibly on 
both while the application level process 42 runs on the 
APU 20 or the NIU 32. However, in systems that are not 
distributed the same unit may be executing all the proc- 
esses. 

During a messaging operation, a mailbox address 
(typically a called party telephone number, an e-mail ad- 
dress, etc. plus a "domain" identifier) for a message to 
be stored arrives at the application process 42 from one 
of the sources noted above. We will assume for the pur- 
pose of this discussion that a mailbox does not exist on 
the system 1 0 for this address. The message associated 
with the address can arrive at the same time (in the case 
of a network message), later (in the case of a later re- 
corded message) or before (in the case of a recorded 
message to be forwarded) the address is actually re- 
ceived. After the address has arrived, a "check address" 
process 44 of the application process 42 performs an 
operation to determine whether the mailbox address is 
valid. In this operation the check address process 44 
sends a "check address" request 45, which includes a 
mailbox address (usually the telephone number), to a 
"mailbox check" process 46 within the system-level 
processes 40. The mailbox check process 46 accesses 
a subscriber database (not shown) and returns a binary 
indicator to process 44 indicating whether a mailbox ex- 
ists for the mailbox address. In typical systems the mail- 
box check process 46 returns a negative indicator when- 
ever the mailbox was not provisioned and a positive in- 
dicator when the mailbox does exist. In the present in- 
vention, the mailbox check process 46 returns a positive 
indicator 47, indicating that a mailbox exists, even 
though a mailbox does not exist, whenever the system 
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is configured to dynamically cH^Fmailboxes, i.e., dy- 
namic mailbox creation is in effect. 

Once the existence of the mailbox has been 
checked, the application level process (access user in- 
formation) 40 typically executes an "access user infor- s 
mation" process 48 that accesses user information for 
this mailbox. This user information is sometimes called 
a subscriber profile. The user information, or subscriber 
profile, indicates the status of the mailbox, that is, wheth- 
er the mailbox has been activated, whether the sub- 10 
scriber is being provided with a level of service that in- 
cludes voice messaging, etc. To do this, the access user 
information process 48 sends an "access user informa- 
tion" request 49, including the mailbox address, to a sys- 
tem level "mailbox information check" process 50. This is 
process 50 typically returns a read-only copy of the user 
information when a mailbox has been activated, etc. and 
returns a failure indicator otherwise. However, in the 
present invention, the mailbox check process 50 returns 
user information 5 1 to the access user information proc- 20 
ess 48 by providing "default" user information whenever 
the mailbox does not exist and dynamic mailbox crea- 
tion is enabled. The default user information includes, 
among other things, a default name announcement that 
announces the called telephone number as the name of 25 
the mailbox and states that the caller can leave a mes- 
sage. The default name announcement is similar to the 
one used when a subscriber fails to record a name an- 
nouncement. 

Once the user information has been accessed, the 30 
application-level process 42 performs an "obtain mes- 
sage" process 52 that typically obtains or gets the mes- 
sage that is to be stored. In the case of a voice message 
that is being recorded by a calling party this operation 
involves the APU 20 recording the message, allowing 35 
the calling party to change the message, mark it urgent, 
etc. In the case of a message transferred from another 
system 30 or a message from the Internet 34, this in- 
volves extracting the message from the network mes- 
sage received by the NIL) 32. Because the mailbox has 40 
not yet been created at this step, if the calling party 
hangs up prior to recording a message, erases the mes- 
sage before exiting, the application detects that only si- 
lence has been recorded, etc. such that a valid message 
has not been recorded, the system exits to a wait state 45 
without completing the mailbox creation process and the 
message, if any, is discarded. 

After a message is obtained that is to be stored, the 
application level process 42 performs a "get user infor- 
mation" process 54 that obtains the user information so 
necessary to store the message. This process 54 es- 
sentially makes a request 55 ("get user information") to 
lock out other applications from obtaining the subscriber 
information, so that the process of storing the message 
and updating the message information for the subscrib- ss 
er can be executed without errors that can be caused in 
race situations. At the system level a "mailbox get infor- 
mation" process 56 typically obtains a lock index 57 for 
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the subscriber record an<WPTirns it to the application. 
Prior to returning the lock index, at this step in process 
56, the present invention creates a mailbox that has the 
default subscriber information previously sent to the ap- 
plication process 42. This creation process also flags 
the mailbox as having been dynamically created. As can 
be seen, the mailbox is created at the time that a request 
for the storage of the message is pending. Mailboxes 
are also created for any called parties that are on a 
group distribution list created by the calling party when 
the mailboxes do not exist. The mailboxes are created 
at the time the calling party activates the deliver mes- 
sage function after recording a message. 

After the look index 57 is received, the application 
level 42 performs a "storage process" 58 ("put user in- 
formation") where; (1 ) the message is stored in a mes- 
sage file on a nonvolatile storage media, such as a hard 
disk; (2) a header for the message file is created; (3) the 
subscriber information is updated by increasing the 
message count by one; and (4) a pointer to the message 
file is stored in the subscriber list of messages. This up- 
dated information 59, along with the lock index, is re- 
turned to a "mailbox information put" process 60 at the 
system-level 40 that typically updates the subscriber da- 
tabase with the updated information and releases the 
subscriber record lock. 

The message is now ready for delivery 62 to the 
called party. The message can be delivered in one of 
several ways. The presence of the message can be in- 
dicated to the called party by, e.g., a "stutter dial tone" 
or a message light for a telephone. The called party can 
then retrieve the message, either by telephone or com- 
puter. The message can also be delivered by performing 
a conventional "outdial" process. Alternatively, the mes- 
sage can be transferred to another system 30 via the 
NIU 32. The message can be converted into an e-mail 
message and transferred through the Internet 34. The 
message can also be converted into a text message and 
sent by a text facility, such as facsimile (not shown). 

The processes discussed above are stored in a 
storage medium of the system 10, such as on disk, in 
RAM, etc. 

To insure that mailboxes are not created for tele- 
phone numbers that do not exist or for numbers that 
should not have mailboxes, such as pay telephone num- 
bers, several different validity checks can be performed. 
During the check address process 44, the called party 
or message recipient's teleptone number or network ad- 
dress can be checked against standard references. For 
example, a telephone number can be range-checked 
and checked for sufficient digits. A network address can 
be domain-name checked. It is also possible, using the 
outdial process, to dial the called party's number to 
check for an "operator intercept" tone that indicates that 
the telephone number is invalid. The system could also 
send a query to a separate database over a network 
such as the Internet 34. These approaches to verifica- 
tion could be used to avoid creating the mailbox and 
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storing the message if the addH^is invalid. 

The present invention will also create a mailbox for 
a subscriber that is attempting to log-in to the system 
when the system has not yet been provisioned with a 
mailbox for the subscriber by the system administrator. 
In this situation, when the user attempts to log-in the 
system uses the telephone number, received via the 
methods previously noted, and accesses 48, as previ- 
ously discussed, the user information to particularly ob- 
tain the information indicating whether the mailbox has 
been initiated as depicted in figure 3. The application 
level process checks 63 this information and if the mail- 
box has been initiated the process exits to the normal 
log-in procedure. If the mailbox has not been created 
the subscriber is given the opportunity to choose 64 a 
password and record 66 a name announcement. Once 
this is done the user information is obtained 54 as pre- 
viously discussed. It is at this time that the mailbox is 
created and if the user stops before his step, such as by 
hanging up, the mailbox is not created. The mailbox in- 
formation, such as passcode, name announcement and 
greeting, is updated 68. The updated information is then 
stored 58, as previously discussed. 

To prevent a hacker from creating a mailbox from a 
pay telephone, the system only allows a mailbox to be 
created by a subscriber from their own telephone which 
is confirmed by the arrival of "automatic number identi- 
fication' (ANI) information for the subscriber at the CU 
24. In this situation, pay telephones, and other phones 
that are not authorized for a mailbox, must be configured 
not to submit ANI when calling message platforms. 

After the mailbox is created and the message is 
stored, it is also possible to perform a validity check. The 
outdial process can be used to call the recipient's tele- 
phone and prompt the person answering the telephone 
to indicate whether a message stored for the number is 
valid. This can also be used as an opportunity to obtain 
the correct subscriber information to substitute for the 
default information. In a situation where the service pro- 
vider levies a fee for the messaging service, this can be 
an opportunity to sign up a new subscriber. If the user 
does not subscribe to the service the mailbox can be 
flagged as receive-only and the called party billed for 
each message received, including the current or subse- 
quent messages whenever they are retrieved. 

It is also possible and preferable to validate a dy- 
namically-created mailbox address using the "message 
waiting indication" (MWI) features of the CO switch 16. 
This check can occur in the check address process 44 
or mailbox check process 46 or after the message is 
stored. Figure 4 depicts such a validation process 70. 
The validation process 70 is performed preferably at the 
system-level 40. The validation process 70 creates 72 
an MWI packet that is sent 74 by the CU 24 to the CO 
switch 16 via the SMDI link. If the CO switch 16 deter- 
mines that the address does not correspond to a legiti- 
mate telephone subscriber or the address corresponds 
to a number that should not have a mailbox (e.g. a pay 



telephone), the CO switc^W returns a message (an 
invalid MWI packet) indicating that the address is 
invalid. The system 10 checks 76 this indication and, if 
the address is not valid, marks 78 the mailbox as disa- 

s bled, thereby preventing access to the mailbox and pre- 
venting additional messages from being saved. The 
system also sends an alarm to a systems administrator. 

Note that disabling a mailbox does not destroy any 
messages that are currently stored in the mailbox. This 

w js because a problem could have been caused in the 
end-office (such as MWI not being enabled for the sub- 
scriber's telephone). The administrator, based on the 
alarm, can investigate, discover the problem and re-en- 
able the mailbox using the conventional system admin- 

15 istrator commands, thus permitting the subscriber to re- 
trieve the message. 

It is possible for the calling party to enter a called- 
party number that is in error but which passes the vali- 
dation tests previously discussed. In such a situation, 

20 after a period of time sufficient for the called party to 
have retrieved the message, the system 10 can perform 
an outdial process, or other suitable notification process 
if the message was received over the Internet 34, to the 
calling party to inform the calling party with a standard 

25 message that the message has not been retrieved. This 
outdial notification can announce the called party's 
number and play the message for the calling party if de- 
sired, thereby returning the unretrieved message. The 
calling party can then be given the opportunity to enter 

30 a correct number or delete the message. 

To ensure that only active mailboxes are retained, 
both a mailbox retention time (or a mailbox expiration 
date) for dynamically-created mailboxes and a mail re- 
tention time (or mail expiration date) for messages as- 

35 sociated therewith can be provided. The time period for 
messages should be set for less than that of mailboxes. 
When the message retention time period expires, the 
message is set for deletion and the system 10 deletes 
(purges) the message just as saved messages are de- 

40 leted at the end of their expiration period. When the mail- 
box retention time has elapsed, the record for the dy- 
namically-created mailbox is deleted. If a mailbox is nev- 
er accessed, and therefor never initialized, and has no 
messages, the mailbox is deleted. Messages that reside 

45 jn mailboxes that were not dynamically created, that is, 
that were created by a system administrator or by the 
subscriber logging-in and initializing a mailbox, are not 
provided dynamic expiration dates. Instead, these mail- 
boxes receive expiration dates in accordance with the 

50 conventional expiration policy configured into the sys- 
tem by the service provider. 

The present invention has been described with re- 
spect to creating a mailbox when there is a need to store 
a message in the mailbox. However, any event that 

55 would modify an attribute of a mailbox, such as subscrib- 
er initialization, could trigger the creation of a mailbox 
where one has not been previously provisioned when 
dynamic mailbox creation is enabled. 
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The dynamic creation and^Wrage of a message 
can be prevented, for example, when a telephony serv- 
ice subscriber (such as an elcerly person) does not want 
voice mail service, by provisioning the mailbox and 
marking it disabled. 

As discussed above, the present invention does not 
create a mailbox until some attribute of the mailbox 
needs to be updated (a message is to be stored/deliv- 
ered, the subscriber initializes the mailbox, etc.). Prior 
to an attribute modification, the system presents a read 
only view of the mailbox to the user, but the system does 
not actually create the mailbox. This has the benefit of 
not wasting resources on a mailbox until the system 
knows that a mailbox is required. For example, if a call 
is forwarded to the system, and the mailbox does not 
exist, then the system will pretend (from the caller's point 
of view) that the mailbox exists so that the caller may 
leave a message. If the caller decides to abort the call, 
and does not leave a message, then the mailbox is not 
created. If the caller chooses to leave a message, how- 
ever, then a mailbox is created to receive the message 
left. As is described previously, there are mechanisms 
for deleting mailboxes that were created automatically, 
but which the subscriber did not use during some preset 
amount of allotted time. This is the preferred embodi- 
ment. 

However, in an alternace embodiment the system 
creates the mailbox immediately upon call arrival, even 
to provide the read access for the mailbox. In this em- 
bodiment, the mailbox will exist even if the caller does 
not leave a message. However, the platform can keep 
track of whether or not a mailbox attribute was modified 
during the course of the call (message deposit, sub- 
scriber initilization, etc.). If no attribute of the mailbox 
was modified during the course of the call, then the plat- 
form will delete the mailbox after the call is completed. 
While this wastes some platform resources (needlessly 
creating and then deleting the mailbox), it achieves a 
similar goal to the preferred embodiment. 

In a further embodiment the system creates the 
mailbox immediately upon call arrival, even to provide 
read access for the mailbox (as in the alternate embod- 
iment outlined above), but does not attempt to keep 
track of whether or not any mailbox attributes were mod- 
ified during the course of the call. Instead, the system 
relies on the mechanism outlined in the preferred em- 
bodiment which will delete dynamically created mailbox- 
es that are not used during the preset allotted time - and 
so, the mailbox created for read access - and never 
modified - is deleted from the system automatically at a 
later date. While this also wastes system resources, it 
postpones the impact of the delete operation to a period 
of low system activity, thus minimizing the system re- 
source expense of deleting the mailbox. 

The many features and advantages of the invention 
are apparent from the detailed specification and, thus, 
it is intended by the appended claims to cover all such 
features and advantages of the invention which fall with- 
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in the true spirit and scdj^^f the invention. Further, 
since numerous modifications and changes will readily 
occur to those skilled in the art, it is not desired to limit 
the invention to the exact construction and operation il- 
lustrated and described, and accordingly all suitable 
modifications and equivalents may be resorted to, falling 
within the scope of the invention. 
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A method of creating a message mailbox, compris- 
ing: 

receiving a message to be stored; and 
creating a mailbox for the message at a time 
that the mailbox is needed if the mailbox does 
not exist. 

A method as recited in claim 1 , wherein a mailbox 
is needed when one of a time for a message to be 
stored and a mailbox attribute is to be modified. 

A method as recited in claim 1 , further comprising 
verifying mailbox validity by testing whether a mail- 
box address is authorized for a predetermined serv- 
ice. 

A method as recited in claim 3, wherein said prede- 
termined service is message waiting indication. 



5. A method as recited in claim 1, further comprising: 

storing the message; 

deleting the message after a message expira- 
tion time period when the message is not re- 
trieved; and 

deleting the mailbox when the mailbox has 
been dynamically created, has not been ac- 
cessed and is empty for a predetermined mail- 
box expiration time period. 

6. A method as recited in claim 1 , further comprising: 

storing the message; and 
attempting to deliver the message by contact- 
ing an address of the mailbox. 

7. A system for creating a message mailbox, compris- 
ing: 

a message processing system, comprising: 

an application level process that requests 
storage of a message; and 
a system level process that creates a mail- 
box upon the request for storage if the mail- 
box does not exist. 
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8. A system as recited in cWW, wherein said appli- 
cation level process requests verification of the ex- 
istence of a mailbox for a mailbox address and said 
system level process verifies existence of the mail- 
box when dynamic mailbox creation is enabled and 
a mailbox does act exist for the address. 



# 

essBge 1 



receiving a message to be stored; and 
enabling a mailbox for use at a time that the 
mailbox is needed if the mailbox does not exist. 

14. A method of creating a message mailbox, compris- 
ing: 



9. A system as recited in claim 8, wherein said appli- 
cation level process requests subscriber informa- 
tion for a subscriber with the mailbox address and 
said system level process provide default subscrib- 
er information when dynamic mailbox creation is 
enabled, and a mailbox does not exist for the ad- 
dress. 

10. A system as recited in claim 9, wherein said mailbox 
is created using the default subscriber information. 

11. A storage medium storing a message mailbox cre- 
ation process creating a mailbox at a time that a 
message is to be stored if the mailbox does not ex- 
ist. 

12. A method of creating a message mailbox, compris- 
ing: 



determining that a mailbox attribute needs to 
be modified; and 
10 enabling a mailbox for use at a time that the 

mailbox is needed for attribute modification if 
the mailbox does not exist. 

15. A method of managing a message mailbox, corn- 
's prising: 

creating a mailbox upon call arrival if the mail- 
box does not exist; and 

deleting the mailbox when the mailbox is not 
20 used within a predetermined period of time. 

16. A method of managing a message mailbox, com- 
prising: 

25 creating a mailbox upon call arrival if the mail- 

box does not exist; and 
deleting the mailbox when an attribute of the 
mail box is not modified during the call. 



receiving an address of a mailbox in which a 
message is to be stored; 
overriding mailbox validation rejection and cre- 
ating a subscriber record containing default in- 30 
formation when a mailbox for the address does 
not exist and dynamic mailbox creation is ena- 
bled; 

receiving a message to be stored; 
creating a mailbox at a time that the message 35 
is to be stored using the default subscriber in- 
formation and flagging the mailbox as being dy- 
namically created; 
storing the message in the mailbox; 
verifying mailbox validity by testing whether a 40 
mailbox address is authorized for a message 
waiting indication; 

issuing a message to check the maiibox when 
message waiting indication is not authorized; 
returning the message to a sender when it is 4$ 
not retrieved within a retrieval time period; 
deleting the message after a message expira- 
tion time period when the message is not re- 
trieved; 

deleting the mailbox when the mailbox has so 
been dynamically created, has not been ac- 
cessed and is empty for a predetermined mail- 
box expiration time period; and 
playing the message when a request to play the 
message is received from the mailbox address. 55 
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ing: 
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